[00:00.000 --> 00:01.440]  All right, we're back.
[00:01.580 --> 00:03.800]  And thank you, Alvaro, for supporting the community,
[00:03.800 --> 00:07.500]  supporting DEF CON, for, of course, presenting here,
[00:07.500 --> 00:09.880]  and definitely supporting the Red Team Village as well.
[00:10.820 --> 00:13.260]  We're glad to have you here, and the floor is yours.
[00:13.260 --> 00:14.100]  Take it away.
[00:14.480 --> 00:15.620]  Thank you so much, Omar.
[00:15.620 --> 00:17.700]  I'm so happy to be here another year
[00:17.700 --> 00:19.900]  presenting the DEF CON Red Team Village.
[00:19.980 --> 00:21.560]  Welcome to Total Eagresio,
[00:21.560 --> 00:24.760]  Evading Intrusion Detection System for Stealthier Implants.
[00:24.780 --> 00:27.260]  So, first of all, I would like to introduce myself.
[00:27.260 --> 00:30.140]  My name is Alvaro Folgado, hashtag Rebuhacker,
[00:30.140 --> 00:31.780]  and I was a product security engineer
[00:32.360 --> 00:33.700]  where I perform a lot of software
[00:33.700 --> 00:35.560]  and architecture security reviews.
[00:35.560 --> 00:39.060]  I do a lot of offensive appsec, bug hunting,
[00:39.420 --> 00:41.820]  a little bit of research about this last topic.
[00:41.820 --> 00:43.880]  But in my free time, I have been spending
[00:43.880 --> 00:45.520]  more or less the last two years
[00:45.520 --> 00:49.540]  working on a main project that is an implant framework.
[00:49.760 --> 00:51.380]  It's kind of divided in two parts.
[00:51.380 --> 00:54.140]  The first part is the C2 operation manager,
[00:54.140 --> 00:55.220]  that is grown on Golang.
[00:55.720 --> 00:57.520]  Most of it, like, it used Terraform
[00:57.520 --> 01:00.660]  to deploy, like, infrastructure, proxies, and redirectors.
[01:00.660 --> 01:02.760]  And the other half is the modular Vegeto
[01:02.760 --> 01:04.840]  that is grown on Go, C++, and OGTC
[01:04.840 --> 01:06.440]  to perform a little bit more of, like,
[01:06.440 --> 01:09.080]  native action over the target device.
[01:09.080 --> 01:10.980]  I have the lag in the past, as I say,
[01:10.980 --> 01:14.200]  to present this framework on the DEF CON Red Team Village
[01:14.200 --> 01:16.020]  of the past year alongside Shellcon.
[01:16.020 --> 01:18.280]  I am here again to speak a little bit
[01:18.280 --> 01:19.740]  of this kind of same topic,
[01:19.740 --> 01:22.760]  but connected to other stuff that I'm gonna develop.
[01:22.760 --> 01:25.040]  So the connection here, it's, you know,
[01:25.040 --> 01:28.340]  in the last year when I was presenting this framework,
[01:28.340 --> 01:31.280]  one of the stuff that I was kind of most proud about
[01:31.280 --> 01:34.220]  is, like, the ability of my implant of egressing,
[01:34.220 --> 01:37.120]  not just using HTTPS against a custom server,
[01:37.120 --> 01:38.680]  but using Gmail itself.
[01:39.040 --> 01:41.000]  And I was saying in my talk, like, you know,
[01:41.000 --> 01:43.300]  give me a string to egress and I should hack the planet
[01:43.300 --> 01:44.640]  because, you know, you can use Gmail,
[01:44.640 --> 01:46.960]  but you can use any other software service.
[01:47.240 --> 01:48.620]  And from that talk,
[01:48.620 --> 01:51.100]  I got an amazing amount of cool feedback.
[01:51.100 --> 01:53.280]  But, you know, one of the most interesting one
[01:53.280 --> 01:56.400]  was from one Blue Team engineer back then
[01:56.400 --> 01:59.300]  that told me, you know, this looks cool,
[01:59.300 --> 02:02.000]  but you know that by analyzing some header of your flow,
[02:02.000 --> 02:03.520]  like the TLS fingerprints,
[02:03.520 --> 02:06.660]  we could perfectly detect that that's a Go HTTP client.
[02:06.660 --> 02:08.320]  And, you know, if we kind of,
[02:08.320 --> 02:09.840]  while this is the kind of software we have
[02:09.840 --> 02:11.900]  in the domain host of a corporate network,
[02:11.900 --> 02:13.280]  that will look sketchy.
[02:13.280 --> 02:16.100]  So I was like, okay, so you're telling me
[02:16.100 --> 02:17.340]  I am egressing through Gmail,
[02:17.340 --> 02:19.860]  but still not even by, you know,
[02:19.860 --> 02:21.060]  doing a deep packet inspection,
[02:21.060 --> 02:23.640]  we are able to detect I'm using some kind of malware.
[02:23.740 --> 02:25.820]  So, you know, this really triggered my attention.
[02:25.820 --> 02:28.400]  So I focused my next year research on them
[02:29.240 --> 02:32.260]  towards like creating kind of an skeletal network model,
[02:32.260 --> 02:33.260]  not just for my tool,
[02:33.260 --> 02:35.980]  but also as a piece of code for every,
[02:35.980 --> 02:39.740]  everything around the community to be able to use this
[02:39.740 --> 02:43.160]  for bypassing this kind of filtering of this kind of rules
[02:43.160 --> 02:44.580]  that the Blue Team could have
[02:44.580 --> 02:46.880]  deployed in a corporate network.
[02:46.880 --> 02:50.620]  So, you know, if we focus on this, you know,
[02:50.620 --> 02:54.400]  on this field and we really want to like look stealthy
[02:54.400 --> 02:55.700]  on the network level,
[02:55.700 --> 02:58.600]  I wanted to start a little bit like a high level vision
[02:58.600 --> 03:00.680]  of kind of the different techniques
[03:00.680 --> 03:03.260]  that the Blue Team could deploy in a corporate network
[03:03.260 --> 03:05.840]  towards detecting or running implant in a foothold
[03:05.840 --> 03:08.020]  just by looking at the network package.
[03:08.020 --> 03:11.580]  So I like to divide in kind of like two big parts, right?
[03:11.580 --> 03:14.480]  We have all the deep packet inspection techniques
[03:14.480 --> 03:18.200]  where, you know, somehow the Blue Team has deployed
[03:18.840 --> 03:21.440]  the infrastructure to force every domain host
[03:21.440 --> 03:23.900]  network package to go through a proxy, right?
[03:23.900 --> 03:25.660]  And this proxy normally is a TLS proxy
[03:26.620 --> 03:28.640]  that filter out all this flow
[03:28.640 --> 03:31.520]  and make the target operating system
[03:31.520 --> 03:33.100]  all up to accept the certificates.
[03:33.100 --> 03:35.740]  So I can deep look at the body of the flow.
[03:35.740 --> 03:37.840]  And then, you know, by looking at this body,
[03:37.840 --> 03:40.380]  I can get kind of common strings that match to malware
[03:40.380 --> 03:43.780]  and I can try to create a set of fine grained rules
[03:43.780 --> 03:45.980]  to detect which one are the flows that match
[03:45.980 --> 03:48.580]  most common like indicative of compromise
[03:48.580 --> 03:50.600]  and most common like problems, right?
[03:50.820 --> 03:53.740]  But I'm not gonna get still really deep
[03:53.740 --> 03:54.740]  into these techniques.
[03:54.740 --> 03:56.000]  I want to focus a little bit
[03:56.000 --> 03:58.560]  in not deep packet inspection techniques, right?
[03:58.980 --> 04:00.760]  That those techniques will be focused
[04:00.760 --> 04:03.100]  not in what the body of the payload is,
[04:03.100 --> 04:06.980]  but more in things like where the aggression is going, right?
[04:06.980 --> 04:10.220]  Which is the server or foothold is connecting to.
[04:10.520 --> 04:12.260]  So, you know, the Blue Team will start to look
[04:12.260 --> 04:14.720]  at things like a sketchy IP range,
[04:14.720 --> 04:18.060]  or if we are using some kind of service like Amazon or Azure,
[04:18.060 --> 04:19.800]  they can start to look at the domain, right?
[04:19.800 --> 04:21.500]  Which kind of domain we are using.
[04:21.540 --> 04:23.680]  And if we use something like domain fronting,
[04:23.680 --> 04:24.660]  they start to look at,
[04:24.660 --> 04:26.740]  oh, which kind of operating system or software
[04:26.740 --> 04:28.880]  is listening to the connection, right?
[04:28.880 --> 04:33.520]  Which kind of certificate is this server like serving?
[04:33.520 --> 04:35.460]  Is self-signed or not?
[04:35.700 --> 04:38.860]  And then they will also could look at the wire itself,
[04:38.860 --> 04:41.220]  you know, which kind of protocol we are using.
[04:41.220 --> 04:46.300]  If there is a huge amount of package load on a DNS aggression,
[04:46.300 --> 04:48.600]  you know, they could say, oh, something is going on here.
[04:48.640 --> 04:52.100]  So, you know, if we come back to the concept
[04:52.100 --> 04:55.440]  of aggressing to a software as a service, like email,
[04:55.440 --> 04:57.860]  then we can finish with all the problems
[04:58.420 --> 05:01.920]  of detection by the endpoint, almost all of them.
[05:01.920 --> 05:04.040]  And we can do this easily because if it's a software
[05:04.040 --> 05:07.140]  as a service, it has the opportunity to modify on a string,
[05:07.140 --> 05:09.760]  we can make our foothold to communicate through the C2
[05:09.760 --> 05:12.060]  just by pulling, pushing data on it.
[05:12.460 --> 05:14.160]  And now it's where you come to the funny part,
[05:14.160 --> 05:16.840]  like we have finished with the problem with the endpoint,
[05:16.840 --> 05:18.920]  but still the blue team has powerful tools
[05:18.920 --> 05:22.100]  to analyze which kind of HTTP client we're using.
[05:22.100 --> 05:24.580]  And they can say, oh, this domain host
[05:24.580 --> 05:25.840]  is using a common browser.
[05:25.840 --> 05:28.860]  That looks good to me, but oh, this human resource laptop
[05:28.860 --> 05:32.300]  is running a Python script to go to whatever server
[05:32.300 --> 05:33.440]  or a Go client.
[05:33.440 --> 05:35.800]  That kind of look a little bit more sketchy.
[05:35.800 --> 05:37.860]  So at the end of the day,
[05:37.860 --> 05:40.680]  the blue team has a powerful tool to analyze
[05:40.680 --> 05:45.140]  before breaking the encryption through TLS fingerprints,
[05:45.140 --> 05:49.060]  which kind of software the foothold is using for this,
[05:49.060 --> 05:50.460]  which kind of software we are using,
[05:50.460 --> 05:52.340]  or redirect, or proxy, or whatever,
[05:52.340 --> 05:53.800]  to receive the connection.
[05:53.800 --> 05:55.660]  And by matching both of them,
[05:55.660 --> 05:58.340]  they could get a really strong indicator of compromise.
[05:59.140 --> 06:01.700]  This will work similarly to like antivirus
[06:01.700 --> 06:04.080]  or host intrusive detective system,
[06:04.080 --> 06:06.360]  where they will extract a hash from the binary
[06:06.360 --> 06:08.240]  and compare it with a public database.
[06:08.240 --> 06:10.780]  Instead of now doing that with the binary,
[06:10.780 --> 06:12.820]  they will do that with a TLS handshake,
[06:12.820 --> 06:15.280]  and they will extract a certain number of bytes,
[06:15.280 --> 06:17.900]  perform a hash, and compare it with a public database.
[06:17.900 --> 06:19.900]  This is around a really interesting research
[06:19.900 --> 06:23.720]  that was done time ago by a bunch of blue team engineers.
[06:23.920 --> 06:25.980]  And alongside with this research,
[06:25.980 --> 06:28.600]  they publish it with this GA3 tool.
[06:28.600 --> 06:29.960]  This is a Python script.
[06:30.260 --> 06:32.400]  I'm going to do a little bit of a deep dive,
[06:32.400 --> 06:33.120]  what's going on.
[06:33.120 --> 06:35.320]  So let's imagine we're writing our implant,
[06:35.320 --> 06:38.140]  and now we need to think about how he's going to egress
[06:38.140 --> 06:40.300]  or how he's going to connect to the C2, right?
[06:40.300 --> 06:43.140]  So if we are going to use HTTPS,
[06:43.140 --> 06:44.540]  and a lot of you will say,
[06:44.540 --> 06:46.480]  okay, don't use HTTPS, use HTTP,
[06:46.480 --> 06:48.940]  but for some reason we need to use HTTPS,
[06:48.940 --> 06:51.800]  or endpoint for some reason uses HTTPS.
[06:51.800 --> 06:53.800]  The first thing that our implant will perform
[06:53.800 --> 06:55.500]  is opening a TCP socket.
[06:55.860 --> 06:57.820]  And following that TCP socket,
[06:57.820 --> 06:59.740]  the TLS handshake will start.
[07:00.140 --> 07:03.720]  And that TLS handshake has a lot of information on it,
[07:03.720 --> 07:06.600]  because first the client is going to tell to the server
[07:06.600 --> 07:09.060]  which kind of TLS version we want to use,
[07:09.060 --> 07:11.120]  which kind of C4CZ you want to use,
[07:11.120 --> 07:14.120]  but particularly which kind of extension you want to use.
[07:14.120 --> 07:15.640]  And a lot of these bytes,
[07:15.640 --> 07:18.380]  they're really related to the kind of software we are using
[07:18.380 --> 07:20.920]  or the kind of library we are using to write our implant.
[07:21.000 --> 07:23.600]  In the same way, the server will do the same.
[07:23.700 --> 07:27.280]  So the Python script will parse this pickup of,
[07:27.280 --> 07:28.840]  you know, if we're using YSHA or any other software
[07:28.840 --> 07:33.300]  to get them, and then we'll just select this package
[07:33.300 --> 07:36.940]  and we'll analyze the bytes, transform them in MD5 hash
[07:36.940 --> 07:39.180]  and match them to a really particular software.
[07:39.600 --> 07:41.460]  If we're writing with our implant,
[07:41.460 --> 07:43.400]  sometimes we rely on those libraries,
[07:43.400 --> 07:45.240]  and other times we're going to use some software
[07:45.240 --> 07:47.080]  that is already matched,
[07:47.080 --> 07:48.580]  and it's already like,
[07:48.580 --> 07:52.480]  give us a really particular alert to the blue timers.
[07:52.940 --> 07:54.240]  So if you follow the source code,
[07:54.240 --> 07:55.460]  you can go to the GF3 tool
[07:55.460 --> 07:57.800]  and see exactly what he's doing when you provide
[07:57.800 --> 07:59.500]  to the Python script a pickup.
[07:59.540 --> 08:01.800]  But if we go to the YSHA,
[08:01.800 --> 08:05.000]  and we start to listen to the flows,
[08:05.000 --> 08:06.120]  and we just open a browser
[08:06.620 --> 08:08.660]  that is performing HTTPS connection,
[08:08.660 --> 08:10.320]  we can easily filter those package
[08:10.320 --> 08:12.180]  and we can see what's going on.
[08:12.180 --> 08:14.560]  We can go to the header of the SQL Socket layer
[08:14.560 --> 08:17.740]  and we can see all these particular bytes that we have.
[08:17.800 --> 08:21.220]  And while TLS version and CIFS are kind of easy to modify,
[08:21.220 --> 08:23.380]  there is a bunch of extension that are assisted
[08:24.280 --> 08:26.760]  by the RFC that can be configured.
[08:26.760 --> 08:30.880]  So the Python script will just go over that set of package,
[08:30.880 --> 08:33.420]  divide those bytes in five section,
[08:33.420 --> 08:34.940]  transform them in hexadecimal,
[08:34.940 --> 08:36.960]  and then generate this MD5 hash
[08:36.960 --> 08:40.600]  that particularly match a certain version of a server
[08:40.600 --> 08:42.080]  for the client and the server.
[08:42.220 --> 08:44.360]  So, okay, where are the red timers?
[08:44.620 --> 08:45.780]  We know this is a problem
[08:45.780 --> 08:48.840]  and we know that we may be detected because of this.
[08:48.900 --> 08:50.720]  So now it's where it becomes the idea
[08:50.720 --> 08:52.040]  of blending in the network
[08:52.040 --> 08:56.460]  and trying to like evading these techniques, right?
[08:56.460 --> 08:58.300]  So I had a bunch of ideas.
[08:58.300 --> 09:00.200]  My first idea was,
[09:00.200 --> 09:02.480]  okay, I'm using a programming language.
[09:02.480 --> 09:04.000]  This programming language gave me the option
[09:04.000 --> 09:06.300]  to create my own HTTP client,
[09:06.300 --> 09:07.760]  choose the library I want to.
[09:07.840 --> 09:10.080]  But the problem is like most of the HTTP clients
[09:10.080 --> 09:12.100]  that accept TLS configuration,
[09:12.100 --> 09:14.200]  while they provide you a lot of bytes
[09:14.200 --> 09:16.740]  for configuring your own TLS handshake,
[09:16.740 --> 09:18.580]  they really don't provide you like an input
[09:18.580 --> 09:20.260]  where you can put all the bytes you like
[09:20.260 --> 09:21.320]  and the order you like.
[09:21.320 --> 09:23.280]  So you can have the hash to decide
[09:23.280 --> 09:26.060]  for copying another client software.
[09:26.320 --> 09:28.520]  So this was kind of a tricky one.
[09:28.520 --> 09:30.720]  So my next idea was, okay,
[09:30.720 --> 09:33.260]  I will just open a TCP socket
[09:33.260 --> 09:36.520]  and throw there my copy client hello package
[09:36.520 --> 09:37.460]  and see what happened.
[09:37.460 --> 09:39.140]  Obviously the TLS handshake breaks
[09:39.140 --> 09:40.780]  and it's not interesting to us
[09:40.780 --> 09:41.840]  because at the end of the day,
[09:41.840 --> 09:43.540]  we need to use HTTPS.
[09:43.780 --> 09:47.120]  So my last option were like getting a little bit
[09:47.120 --> 09:49.140]  my hands dirty and go and modify
[09:49.680 --> 09:52.440]  the source code of the programming language
[09:52.440 --> 09:54.400]  I was using in this case was Golang.
[09:54.400 --> 09:56.380]  So I will say, okay, I will add a feature
[09:56.900 --> 09:59.080]  and this is more or less how it works.
[09:59.860 --> 10:01.980]  So, you know, and I'm sort of similar
[10:01.980 --> 10:03.980]  in other languages that relate
[10:03.980 --> 10:05.140]  to which kind of language you're using
[10:05.140 --> 10:06.000]  for writing your input,
[10:06.000 --> 10:07.600]  but at least in Golang,
[10:08.040 --> 10:09.160]  when you want to address,
[10:09.160 --> 10:10.780]  you need to graph your HTTP client.
[10:10.820 --> 10:11.980]  And when you graph the HTTP client
[10:11.980 --> 10:13.320]  and you want to use HTTPS,
[10:13.320 --> 10:14.680]  you provide the TLS configuration
[10:14.680 --> 10:15.860]  that is like a struct.
[10:17.080 --> 10:19.140]  Before requesting to the endpoint
[10:19.140 --> 10:20.240]  with a post get,
[10:20.240 --> 10:22.220]  whatever HTTP request you want to,
[10:23.760 --> 10:25.040]  the language will go through
[10:25.040 --> 10:28.240]  the flow of crafting this TLS hello.
[10:28.260 --> 10:29.900]  And it will take kind of your configuration
[10:30.400 --> 10:33.020]  and then grab up the bytes
[10:33.020 --> 10:34.780]  and send them to perform the handshake.
[10:34.780 --> 10:36.140]  The problem is, I was telling before,
[10:36.140 --> 10:36.940]  we don't have a feature
[10:36.940 --> 10:40.080]  where we can like put whatever bytes we want to.
[10:40.080 --> 10:43.520]  So I modify the source code of Golang
[10:43.520 --> 10:45.280]  and HTTP client to accept
[10:45.280 --> 10:46.740]  in the TLS configuration,
[10:46.860 --> 10:48.080]  a new string input.
[10:48.080 --> 10:50.520]  And this string input will be exactly
[10:51.020 --> 10:53.520]  what the GF3 tool provide to us.
[10:53.520 --> 10:54.400]  So in that case,
[10:54.400 --> 10:56.260]  we can use like GF3 tool
[10:56.260 --> 10:59.100]  for copying a Chrome Firefox Opera browser
[10:59.100 --> 11:02.280]  and throwing in the compilation of our implant.
[11:02.560 --> 11:05.300]  In that way, when you go to TLS,
[11:05.300 --> 11:06.760]  the TLS flow,
[11:06.760 --> 11:08.400]  and you need to add another part of the code
[11:08.400 --> 11:09.880]  where you are like marshalling
[11:09.880 --> 11:11.740]  or creating this client hello,
[11:11.740 --> 11:12.700]  I added a for loop
[11:12.700 --> 11:15.360]  and for each hexadecimal value,
[11:15.360 --> 11:17.060]  I kind of copy a reference,
[11:17.060 --> 11:17.860]  which is the package
[11:17.860 --> 11:20.900]  or the syntax that respect the RPC.
[11:21.020 --> 11:21.920]  So if you have a bunch
[11:21.920 --> 11:23.800]  of hexadecimal bytes in the right order,
[11:23.800 --> 11:25.060]  you can extract the fingerprint
[11:25.060 --> 11:27.260]  of the browser you are targeting.
[11:27.700 --> 11:29.420]  It's true that a lot of them,
[11:29.420 --> 11:30.400]  and I'm sure this extension
[11:30.400 --> 11:32.740]  will be like modified with the time,
[11:32.740 --> 11:34.560]  but I have enough right now,
[11:34.560 --> 11:37.060]  entropy or availability
[11:37.060 --> 11:39.400]  of like hexadecimal bytes already caught
[11:39.400 --> 11:41.380]  for like accepting most of the browser.
[11:41.380 --> 11:42.240]  If you feel that you need
[11:42.240 --> 11:43.360]  more hexadecimal bytes,
[11:43.360 --> 11:44.520]  I will add them.
[11:44.600 --> 11:45.300]  There is no problem.
[11:45.300 --> 11:46.360]  The source code is already published
[11:46.360 --> 11:48.260]  in these links on GitHub.
[11:48.480 --> 11:49.100]  So, okay.
[11:49.100 --> 11:51.500]  Now we have the HTTPS client
[11:51.500 --> 11:52.780]  that we need for copying
[11:52.780 --> 11:54.420]  rightful connection of browsers
[11:54.420 --> 11:56.560]  and any other like software you like,
[11:56.560 --> 11:58.580]  antivirus, aggression, whatever.
[11:58.900 --> 12:00.160]  But now it came the problem
[12:00.160 --> 12:02.440]  that we want to address using Gmail.
[12:16.020 --> 12:21.120]  That I need to change on the source code.
[12:21.480 --> 12:23.160]  So that's it.
[12:23.160 --> 12:26.180]  I want to like provide you a flow
[12:26.180 --> 12:28.000]  of how this implant will work
[12:28.000 --> 12:29.000]  on the background,
[12:29.000 --> 12:31.640]  once we get the execution on the foothold.
[12:31.800 --> 12:33.380]  So when we craft our implant,
[12:33.380 --> 12:34.780]  the first thing we need to have
[12:34.780 --> 12:36.760]  is the Gmail connected app.
[12:36.760 --> 12:37.580]  We configure it
[12:37.580 --> 12:38.880]  and we provide those credentials
[12:38.880 --> 12:40.200]  to the C2.
[12:40.200 --> 12:42.040]  And the C2 on the completion of the implant
[12:42.040 --> 12:44.140]  will provide both the credential
[12:44.140 --> 12:46.820]  to the digital alongside
[12:46.820 --> 12:48.200]  with the TLS fingerprint.
[12:48.260 --> 12:49.660]  And then the implant will start
[12:49.660 --> 12:50.460]  with the aggression.
[12:50.460 --> 12:51.200]  And for aggression,
[12:51.200 --> 12:52.040]  the first thing he will do
[12:52.040 --> 12:53.560]  is using the refresh token
[12:53.560 --> 12:55.920]  against the Google authentication servers.
[12:55.920 --> 12:58.120]  And then when he get the access token,
[12:58.120 --> 12:59.860]  we will start to like push,
[12:59.860 --> 13:01.820]  pull information through Gmail.
[13:01.820 --> 13:03.220]  The C2 or the operation server
[13:03.220 --> 13:04.380]  will do similarly.
[13:04.380 --> 13:06.540]  And we could create a data connection
[13:06.540 --> 13:08.680]  for sending or receiving commands perfectly
[13:08.680 --> 13:11.040]  and totally transparent to the operator.
[13:11.260 --> 13:12.440]  At the eyes of the blue team
[13:12.440 --> 13:15.000]  that is looking to this proxy,
[13:15.000 --> 13:17.320]  it will just look like a Chrome browser,
[13:17.320 --> 13:18.740]  which is good to go.
[13:20.260 --> 13:21.780]  So to speak a little bit
[13:21.780 --> 13:22.720]  about DeepPacket inspection
[13:22.720 --> 13:26.240]  or how we can bypass or avoid this stuff.
[13:26.240 --> 13:27.080]  So, you know,
[13:27.080 --> 13:28.500]  if we have the bad luck
[13:28.500 --> 13:29.840]  that the sock or the scissor
[13:29.840 --> 13:31.340]  is gripping common string
[13:32.260 --> 13:34.620]  within or like flow against Gmail,
[13:34.620 --> 13:36.540]  we could kind of use some kind
[13:36.540 --> 13:37.940]  of later cryptography
[13:37.940 --> 13:40.100]  and share a symmetric key with the C2
[13:40.100 --> 13:41.800]  and then common grips
[13:41.800 --> 13:43.740]  or common errors will not pop up.
[13:43.740 --> 13:44.820]  If we have the bad luck
[13:44.820 --> 13:45.880]  that it's a threat hunter
[13:45.880 --> 13:47.260]  catching our flows,
[13:47.260 --> 13:49.700]  we can also use other techniques
[13:49.700 --> 13:51.060]  like stenography.
[13:51.060 --> 13:52.280]  It wouldn't be as difficult
[13:52.280 --> 13:53.920]  because also Gmail provides us
[13:53.920 --> 13:55.140]  the ability to attach images
[13:55.140 --> 13:56.540]  to the draft emails.
[13:57.220 --> 13:59.140]  So a little bit
[13:59.140 --> 14:00.820]  of how the network model
[14:00.820 --> 14:02.540]  with the encryption will work
[14:02.540 --> 14:04.220]  in Siesta time is using
[14:04.220 --> 14:05.420]  the similar thing,
[14:05.420 --> 14:06.680]  putting on the body of the draft
[14:06.680 --> 14:07.720]  whatever JSON payload
[14:07.720 --> 14:09.400]  we want to process by height.
[14:09.400 --> 14:10.720]  But instead of just putting
[14:10.720 --> 14:11.760]  playing the strings,
[14:11.760 --> 14:12.840]  we can use like encrypting
[14:12.840 --> 14:14.240]  with the symmetric key.
[14:14.560 --> 14:15.780]  I have still not developed
[14:15.780 --> 14:16.920]  this full model,
[14:16.920 --> 14:17.680]  but it will be added
[14:17.680 --> 14:19.340]  to Siesta time in the future.
[14:20.360 --> 14:22.160]  So let's let's go ahead
[14:22.160 --> 14:22.920]  with the demo.
[14:22.920 --> 14:24.540]  So what I have created here
[14:24.540 --> 14:25.840]  is trying to reproduce
[14:25.840 --> 14:26.760]  this environment
[14:26.760 --> 14:29.160]  where the blue team has deployed
[14:29.160 --> 14:30.100]  this kind of detection
[14:30.100 --> 14:31.540]  technique in a network.
[14:31.720 --> 14:32.580]  I have created
[14:32.580 --> 14:33.600]  two different implants.
[14:33.600 --> 14:34.680]  This is the graphical interface
[14:34.680 --> 14:35.860]  of Siesta time.
[14:35.860 --> 14:37.200]  And alongside all the inputs
[14:37.200 --> 14:38.320]  that I'm not going to speak
[14:38.320 --> 14:39.460]  about each one of them,
[14:39.460 --> 14:40.780]  particularly we see here
[14:40.780 --> 14:42.340]  we have this TLS fingerprint
[14:42.340 --> 14:44.160]  with an extra 4G S3 tool.
[14:44.160 --> 14:44.880]  In that way,
[14:44.880 --> 14:46.420]  we can create different implants
[14:46.420 --> 14:46.960]  that mimic
[14:46.960 --> 14:48.760]  whatever connection we want to.
[14:49.260 --> 14:50.720]  If we focus a little bit
[14:50.720 --> 14:53.320]  the network topology of the demo,
[14:53.320 --> 14:54.520]  what this is going to look like
[14:54.520 --> 14:56.880]  I am using a BIMI workstation
[14:56.880 --> 14:58.680]  with three machines on it.
[14:58.680 --> 14:59.640]  But particularly interesting
[14:59.640 --> 15:00.840]  is we have the Windows 10
[15:00.840 --> 15:02.400]  foothold that is going to run
[15:02.400 --> 15:03.320]  two different implants
[15:03.320 --> 15:04.280]  and every connection
[15:04.280 --> 15:05.240]  that I get through email
[15:05.800 --> 15:06.620]  is going to be read
[15:06.620 --> 15:08.060]  by a Ubuntu server
[15:08.060 --> 15:10.900]  that is a TLS proxy
[15:10.900 --> 15:11.760]  with Polar Proxy,
[15:11.760 --> 15:13.200]  which is not the most interesting.
[15:13.200 --> 15:13.840]  The important thing
[15:13.840 --> 15:15.140]  is running a Suricata
[15:15.760 --> 15:17.660]  network interface detection system.
[15:18.120 --> 15:19.240]  And you have a bunch of alerts
[15:19.240 --> 15:20.520]  just to like detect
[15:20.520 --> 15:22.000]  that if the TLS fingerprint
[15:22.000 --> 15:23.200]  is not going to the client
[15:23.200 --> 15:24.320]  to show me an alert,
[15:24.320 --> 15:26.040]  if not, you can go ahead.
[15:26.080 --> 15:28.220]  So let's go to the demo.
[15:31.280 --> 15:32.780]  So as you can see here,
[15:32.780 --> 15:33.880]  this is a graphical interface
[15:33.880 --> 15:34.660]  of siesta time.
[15:34.660 --> 15:35.520]  These are all the jobs
[15:35.520 --> 15:37.260]  that the Hive has processed already.
[15:37.380 --> 15:38.920]  And now we have two implants
[15:38.920 --> 15:39.980]  that are created.
[15:40.400 --> 15:41.380]  That means we can just
[15:41.380 --> 15:42.900]  download the executable
[15:42.900 --> 15:44.600]  and somehow we will make
[15:44.600 --> 15:45.580]  the foothold to execute
[15:46.800 --> 15:49.160]  through any attack vector we want to.
[15:49.420 --> 15:51.220]  So this is the Ubuntu machine
[15:51.220 --> 15:52.020]  that is listening
[15:52.020 --> 15:52.780]  to all the connection
[15:52.780 --> 15:54.640]  or the aggression of the foothold.
[15:54.640 --> 15:56.880]  And we have the Suricata running on it.
[15:57.760 --> 15:58.840]  Suricata will match
[15:58.840 --> 16:00.560]  the two following rules.
[16:00.960 --> 16:02.220]  These two rules,
[16:02.220 --> 16:03.340]  they're using a GS3 plugin
[16:03.340 --> 16:04.160]  for Suricata,
[16:04.160 --> 16:06.680]  and they will get the header
[16:06.680 --> 16:07.620]  of the TLS connection
[16:07.620 --> 16:09.340]  of every aggression package.
[16:09.340 --> 16:11.480]  They will generate an MD5 hash.
[16:11.480 --> 16:13.580]  If that hash match this one,
[16:13.580 --> 16:15.180]  we will pop up an alert.
[16:15.580 --> 16:18.080]  We can check that these two hashes,
[16:18.080 --> 16:20.400]  they match by the public database
[16:20.400 --> 16:23.220]  of GS3, a Go HTTP client.
[16:26.490 --> 16:27.750]  So let's search for the hash,
[16:27.750 --> 16:29.030]  similarly to VirusTotal,
[16:29.030 --> 16:30.170]  but with TLS fingerprints.
[16:30.170 --> 16:32.330]  We see this is a Go HTTP client, right?
[16:33.290 --> 16:35.070]  We are going to run the first implant
[16:35.070 --> 16:36.810]  in the Windows 10 foothold
[16:36.810 --> 16:38.750]  and we're going to be detected.
[16:41.970 --> 16:44.110]  So the interesting thing
[16:44.110 --> 16:45.710]  about these two is like,
[16:45.710 --> 16:47.310]  obviously, this Go client
[16:47.310 --> 16:47.870]  is going to be using
[16:47.870 --> 16:49.050]  the default configuration,
[16:49.050 --> 16:50.510]  but we can change things.
[16:50.950 --> 16:52.850]  But the cool thing about this is like,
[16:52.850 --> 16:53.270]  it doesn't matter
[16:53.270 --> 16:54.850]  how many configuration is changed
[16:54.850 --> 16:56.750]  by using a Go HTTP client.
[16:56.750 --> 16:57.770]  By the end of the day,
[16:57.770 --> 16:58.830]  all those hashes,
[16:58.830 --> 16:59.530]  they will be registered
[16:59.530 --> 17:00.870]  with this public database.
[17:00.990 --> 17:02.510]  So we have two appearances
[17:02.510 --> 17:03.650]  on the log of Suricata.
[17:03.650 --> 17:04.370]  And the reason is
[17:04.370 --> 17:06.650]  because I was saying before,
[17:06.650 --> 17:08.530]  one request is for getting the access token
[17:08.530 --> 17:10.850]  for the Google authorization servers.
[17:10.850 --> 17:12.650]  And the second one is for pushing,
[17:12.650 --> 17:15.070]  pulling data from Hive through Gmail.
[17:15.770 --> 17:17.390]  So let's clean the logs.
[17:17.410 --> 17:18.690]  And now we are going to do
[17:18.690 --> 17:19.750]  exactly the same,
[17:19.750 --> 17:21.870]  but using the implant
[17:21.870 --> 17:22.890]  that has been created
[17:22.890 --> 17:24.070]  with siesta time
[17:24.070 --> 17:25.750]  and with the TLS fingerprint
[17:25.750 --> 17:27.350]  of a Chrome browser.
[17:30.250 --> 17:32.590]  So the creation of the implant
[17:32.590 --> 17:33.710]  is just the same process,
[17:33.710 --> 17:34.510]  which is going to change
[17:34.510 --> 17:35.690]  with the execution of it
[17:35.690 --> 17:37.030]  and how we detect it.
[17:37.030 --> 17:38.850]  And the data flow is just the same.
[17:38.850 --> 17:40.550]  So let's execute the implant
[17:40.550 --> 17:42.350]  that now is copying
[17:42.350 --> 17:44.750]  the fingerprint of a Chrome browser.
[17:45.550 --> 17:47.470]  And let's go back to the Suricata.
[17:47.490 --> 17:49.190]  And we see there is no any log,
[17:49.190 --> 17:51.870]  but let's recheck what's going on.
[17:51.870 --> 17:53.450]  So let's open a Wireshark
[17:53.450 --> 17:55.330]  and start to detect
[17:55.330 --> 17:56.730]  and read all the packets
[17:56.730 --> 17:59.650]  that are going through the TLS proxy.
[18:00.590 --> 18:02.750]  And the objective of this is,
[18:02.750 --> 18:04.470]  since we maybe don't trust
[18:04.470 --> 18:06.190]  what Suricata is saying to us, right?
[18:06.190 --> 18:06.850]  Let's make sure
[18:06.850 --> 18:08.530]  that this fingerprint is a Chrome browser
[18:08.530 --> 18:10.570]  instead of a Go HTTP client.
[18:10.570 --> 18:11.730]  So let's filter,
[18:11.730 --> 18:13.570]  let's get all the main hello,
[18:13.570 --> 18:16.170]  and then let's export it in a pickup.
[18:16.770 --> 18:18.230]  And we can use this pickup
[18:18.990 --> 18:21.570]  for like a GS3 to parse it
[18:21.570 --> 18:22.410]  and tell to us
[18:22.410 --> 18:24.050]  which fingerprints of bytes
[18:24.050 --> 18:26.650]  is detecting from this aggression.
[18:28.270 --> 18:30.050]  This way will be the same
[18:30.050 --> 18:31.170]  that we need to follow
[18:31.170 --> 18:32.690]  if we need to copy the TLS fingerprint
[18:32.690 --> 18:34.690]  from any other rightful software.
[18:35.310 --> 18:36.870]  So here you see there is like
[18:36.870 --> 18:38.730]  this five section of bytes.
[18:38.730 --> 18:39.810]  This one will be the input
[18:39.810 --> 18:40.690]  for CSTATIME frame
[18:40.690 --> 18:42.470]  we want to generate an implant
[18:42.470 --> 18:43.590]  with these fingerprints.
[18:43.590 --> 18:45.430]  And there is two different MD5 hashes
[18:45.430 --> 18:48.110]  because as this is a TLS proxy,
[18:48.110 --> 18:49.250]  there is a second fingerprint
[18:49.250 --> 18:51.170]  for polar proxy itself.
[18:51.190 --> 18:53.770]  But if we go and we take the fingerprint
[18:54.130 --> 18:55.150]  of the implant,
[18:56.310 --> 18:57.630]  we are going to see
[18:57.630 --> 19:00.110]  that this is effectively
[19:00.530 --> 19:01.830]  the public database GS3
[19:01.830 --> 19:04.010]  is effectively pointing it
[19:04.010 --> 19:04.890]  to a Chrome browser
[19:04.890 --> 19:06.630]  instead of a Go HTTP client
[19:06.630 --> 19:08.030]  or a Java client,
[19:08.030 --> 19:08.610]  Python client,
[19:08.610 --> 19:10.550]  whatever we have HTTP library
[19:10.550 --> 19:12.950]  we have used for our implant to address.
[19:14.290 --> 19:15.570]  So if we go back
[19:15.570 --> 19:18.690]  to CSTATIME graphical interface,
[19:19.250 --> 19:21.730]  we can see we already have the host infected.
[19:21.830 --> 19:24.210]  We have killed one implant.
[19:24.210 --> 19:24.930]  So that's offline,
[19:24.930 --> 19:26.470]  but the other is still alive.
[19:26.630 --> 19:27.930]  So now we can do things like,
[19:27.930 --> 19:29.330]  you know, injecting a shell
[19:29.330 --> 19:32.810]  or injecting a reverse SQL shell.
[19:32.810 --> 19:34.250]  We have all the information
[19:34.250 --> 19:36.730]  from the target host that we have infected.
[19:36.770 --> 19:38.250]  And we also have like, you know,
[19:38.250 --> 19:40.250]  an asynchronous interactive shell.
[19:40.250 --> 19:41.530]  And all these will happen
[19:42.250 --> 19:43.710]  totally transparent to the operator
[19:43.710 --> 19:44.770]  and through email.
[19:44.770 --> 19:46.570]  You see the fingerprints we need.
[19:48.270 --> 19:48.990]  So,
[19:49.930 --> 19:52.170]  I want to speak last but not least,
[19:52.830 --> 19:54.030]  how to help defender,
[19:54.030 --> 19:54.810]  how to make them better
[19:54.810 --> 19:57.150]  because at the end of the day,
[19:57.150 --> 19:58.790]  you know, the routing operation
[19:58.790 --> 20:01.190]  is have a lot of reason,
[20:01.190 --> 20:02.870]  but we want to make the defenders
[20:02.870 --> 20:03.930]  to be better, right?
[20:03.930 --> 20:05.470]  And to be prepared to this kind of attack.
[20:05.470 --> 20:07.130]  So if I focus on the network
[20:07.130 --> 20:08.410]  intrusive detecting techniques
[20:08.410 --> 20:10.470]  and in the TLS,
[20:10.470 --> 20:12.210]  a fingerprint detection,
[20:12.210 --> 20:14.430]  if you ask me if there is gap of improvement,
[20:14.430 --> 20:16.050]  I will say, yes.
[20:16.790 --> 20:18.370]  There is for one reason
[20:18.370 --> 20:20.850]  that the Python script of GS3,
[20:20.850 --> 20:22.030]  it's, you know,
[20:22.030 --> 20:24.130]  going through all these extensions by it.
[20:24.130 --> 20:26.090]  So they will, the big entropy happens,
[20:26.090 --> 20:27.790]  but it's just taking the headers.
[20:27.790 --> 20:29.190]  You know, the Python screen,
[20:29.190 --> 20:30.470]  we could write a new for loop
[20:30.470 --> 20:32.510]  for like getting more byte inside
[20:32.510 --> 20:34.510]  this like an onion layer, right?
[20:34.510 --> 20:35.950]  And this is something that GS3
[20:35.950 --> 20:37.150]  is not doing right now.
[20:37.150 --> 20:39.030]  That we always generate more md5 hashes
[20:39.030 --> 20:40.030]  and more different
[20:41.470 --> 20:43.150]  entropy to search.
[20:43.150 --> 20:43.890]  But that's it.
[20:43.890 --> 20:44.890]  That's cool.
[20:45.070 --> 20:49.610]  But this is the catch of the mouse.
[20:49.610 --> 20:50.370]  If they do that,
[20:50.370 --> 20:53.350]  I will use another for loop in my HTTPS client
[20:53.350 --> 20:54.770]  and then we're in the same.
[20:54.830 --> 20:55.890]  What I think is interesting
[20:55.890 --> 20:59.170]  is not just using network intrusive detecting technique,
[20:59.170 --> 21:00.070]  but, you know,
[21:00.070 --> 21:02.030]  focusing on the host intrusive detecting techniques
[21:02.030 --> 21:03.430]  or now called EDR
[21:03.430 --> 21:05.610]  and trying to match kind of the two signatures
[21:05.610 --> 21:07.350]  and see if something is going on.
[21:07.350 --> 21:09.290]  I say this because while my VGTO
[21:09.290 --> 21:10.950]  is regressing really efficiently,
[21:10.950 --> 21:14.090]  this is still doing not so like a straightforward actions
[21:14.090 --> 21:15.730]  in the operating system.
[21:15.890 --> 21:17.750]  And, you know, this could be easily detected.
[21:17.770 --> 21:18.410]  Like, you know,
[21:18.410 --> 21:20.850]  when we can see md.x as a forward cell x
[21:20.850 --> 21:23.050]  or for persisting use,
[21:23.050 --> 21:25.750]  calling the APIs of a schedule that's on Windows.
[21:25.910 --> 21:28.670]  This could be like a little bit more like a shiny
[21:28.670 --> 21:30.410]  at the hour of detection.
[21:31.870 --> 21:33.250]  So that's everything.
[21:33.250 --> 21:34.390]  Thank you so much.
[21:34.770 --> 21:37.630]  The source code is already published for everything.
[21:37.630 --> 21:38.790]  And there is a user guide
[21:38.790 --> 21:42.190]  for the CSTATIME framework as well.
[21:44.030 --> 21:46.810]  I have the Discord and I can answer questions.
[21:46.890 --> 21:48.630]  So just let me know.
[21:53.260 --> 21:53.880]  Okay. Yeah.
[21:53.880 --> 21:54.760]  The slides will be,
[21:54.760 --> 21:55.920]  I will publish the slides.
[21:55.920 --> 21:56.580]  Source code is there.
[21:56.580 --> 21:57.460]  There is user guide.
[21:57.460 --> 21:57.940]  Yeah.
[22:02.560 --> 22:03.480]  So that's everything.
[22:03.480 --> 22:04.380]  Thank you so much.
